萌娘百科 talk:讨论版/技术实现/存档/2024年09月
讨论版【技术实现】档案馆
20
21
22
23
24
25年
【BUG】Wikiplus无法正常使用
状态： 无法修复
- 问题
在尝试使用Wikiplus编辑时无法正常获取源代码，获取到的内容中含有“captcha”等字样，可能遇到了验证码。
- 复现步骤
- 开启Wikiplus
- 点击“快速编辑”以打开Wikiplus
- 期望行为
正常显示源码
- 影响范围
全站
--
复活的奥斯曼 理论 及 其 周边 -Ecole de Konstantiniyye- 2024年8月27日 (二) 07:16 (CST)
WikiPlus好像用API的方式获得内容，结果通过这种方法访问记了单独的访问计数，所以就偶发显示人机验证甚至直接429的问题，我自己的解决办法是进去常规编辑模式。✏️
- ( ¡ )题外话 IPE未见有类似问题，这玩意不用API获取吗？--复活的奥斯曼 理论 及 其 周边 -Ecole de Konstantiniyye- 2024年8月28日 (三) 13:37 (CST)
- Wikiplus并未使用API获取内容，一年前星海还在Wikiplus仓库开了个建议使用API获取内容的issue：https://github.com/Wikiplus/Wikiplus/issues/115 。——Dreammu（讨论） 2024年8月28日 (三) 13:45 (CST)
- 感觉跟之前的情形一样吧，都是index.php如果带oldid参数就会要求滑块。使用Special:固定链接/7617279类似的页面进去滑一下可能就可以暂时解决Wikiplus不可用的问题。——Dreammu（讨论） 2024年8月28日 (三) 13:52 (CST)
- (…)吐槽 问题是，这个解决办法并不能恢复Wikiplus在特定情况下的便捷性。在问题解决之前Wikiplus对我来说基本上废了……——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年8月31日 (六) 01:23 (CST)
- 如果您愿意，可以尝试使用我修改后的Wikiplus，这个版本使用API获取页面源代码，在最新版本下不会获取到验证码页面，将以下代码添加进您的个人js页即可：
mw.loader.load("/index.php?title=User:Dreammu/WikiplusSP.js&action=raw&ctype=text/javascript"); - 本来想用内链的但是发现页面似乎会加载超时……只要raw、edit等操作不受影响就好。——Dreammu（讨论） 2024年9月1日 (日) 00:30 (CST)
- 感谢大佬，给大佬磕头了咚咚咚——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月1日 (日) 00:50 (CST)
- 别说，星海说得对，用了API之后，至少只要不是直接编辑全文，保存都能快不少，原来需要的时间跟直接编辑全文没差别。--复活的奥斯曼 理论 及 其周边 -Ecole de Konstantiniyye- 2024年9月1日 (日) 18:41 (CST)
- 如果您愿意，可以尝试使用我修改后的Wikiplus，这个版本使用API获取页面源代码，在最新版本下不会获取到验证码页面，将以下代码添加进您的个人js页即可：
- (…)吐槽 问题是，这个解决办法并不能恢复Wikiplus在特定情况下的便捷性。在问题解决之前Wikiplus对我来说基本上废了……——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年8月31日 (六) 01:23 (CST)
此处原由穆斯塔法凯末尔[更多]于2024年8月30日悬挂的、类型为“问题已答复”的 MAR 因“重复MAR”已被冰风飘羽[更多]于2024年8月31日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的3 日后 (于2024年9月3日凌晨) 存档；U:穆斯塔法凯末尔的留言是“小鱼君在站外给出答复：关于Wikiplus被误伤属无奈之举，最近每天都有人以极高的频率spam相关链接，导致服务器压力过高。可以尝试手动触发一下滑块验证码，获取一段时间的豁免期。因为包括本站只有两个半技术人员在内的一系列原因，目前无法修复。”
问题已答复。
【BUG】审核通知无法正常显示
状态： 已修复
- 问题
自昨晚起，在版本审核完成后，审核结果无法正常通知。（已知：截至Special:固定链接/7608747的编辑可以正常通知审核结果。）
- 复现步骤
- 进行一次非空编辑
- 等待审核通过或被拒绝
- 期望行为
通知中出现“您在 XX 做出的编辑 已通过”之类的审核通知
- 影响范围
全站
--复活的奥斯曼 理论 及 其 周边 -Ecole de Konstantiniyye- 2024年8月23日 (五) 13:48 (CST)
- 似乎jobs卡住了，目前看上去只增不减（echo通知属于jobs）。已通知运维方。—— ほしみ 2024年8月23日 (五) 18:27 (CST)
问题已解决。
———— ほしみ 2024年8月30日 (五) 22:26 (CST)
【BUG】偶发性小部件报错
状态： 无法修复
- 问题
浏览页面时偶尔会报告小部件错误。目前已目击到Widget:LargeNavbox、Widget:NoReferer、Widget:SideBarPic报错，已记录的错误信息包括：
“小部件SideBarPic出错: unable to write file /var/www/wiki/extensions/Widgets/compiled_templates/wrt66c8994bdf08e2_92904892”
“小部件NoReferer出错: unable to write file /var/www/wiki/extensions/Widgets/compiled_templates/wrt66c89b5ebdb878_91329224”（对应页面：好多孩子看到这个根本把持不住#出处，浏览环境：Windows10系统，Edge 版本 127.0.2651.105，vector皮肤）
清除页面缓存后报错自动消失。
- 复现步骤
- 访问一个已创建页面
- 触发条件尚不明确
- 期望行为
浏览页面时小部件正常工作而不报错
- 影响范围
不明，已目击到的报错分别发生于主名字空间和模板名字空间。考虑到小部件应用广泛，可能为全站。
--——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年8月24日 (六) 02:13 (CST)
- (～)补充 应该与浏览环境没有太大关系，因为我、Reiku[更多]等也遇到了这个问题，环境不同。--复活的奥斯曼 理论 及 其 周边 -Ecole de Konstantiniyye- 2024年8月24日 (六) 02:18 (CST)
- 我自己昨天晚上在旧版首页上、今天上午浏览白玉的时候也出现了，看这个路径是linux的www目录路径，铁定是服务器配置问题。--by LJL（讨论） 2024年8月24日 (六) 11:29 (CST)
- 确实，白玉里的Widget:BilibiliUP和Widget:SideBarPic都报错，说明不是单个小部件的问题。--W3jc（讨论） 2024年8月24日 (六) 11:42 (CST)
- (～)补充 访问命令与征服:红色警戒2时遇到了类似的问题：
小部件tochide出错: unable to write file /var/www/wiki/extensions/Widgets/compiled_templates/wrt66c8a01aef8c03_79039189 小部件music163出错: unable to write file /var/www/wiki/extensions/Widgets/compiled_templates/wrt66c8a01b0119c6_50682864
- 另：上面的白玉我访问时未发现报错，据已有经验可能是已经清除过页面缓存所致。——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年8月24日 (六) 21:56 (CST)
此处原由Bicycle_Hikawa[更多]于2024年8月27日悬挂的、类型为“无人回复”的 MAR 因“有新的回复”已被穆斯塔法凯末尔[更多]于2024年8月28日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的10 日后 (于2024年9月7日凌晨) 存档；U:Bicycle_Hikawa的留言是“现在是没怎么见报错了，但是这提报也没见有人理……”
- 这个bug现在甚至蔓延到了共享站，批量上传文件时也会出问题。--复活的奥斯曼 理论 及 其 周边 -Ecole de Konstantiniyye- 2024年8月28日 (三) 13:35 (CST)
- 已复现。错误代码：
小部件Uploader出错: unable to write file /var/www/wiki/extensions/Widgets/compiled_templates/wrt66d1d5540db741_81949475——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年8月30日 (五) 23:54 (CST) - 尝试了一下，清楚页面缓存并不能解决问题，批量上传文件功能现在处于完全不可用状态。——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月1日 (日) 00:54 (CST)
- 已复现。错误代码：
问题已答复。
处理人留言：
据站外回复，系站点遭到外部攻击、运维方临时启用防护措施所致，目前暂无能力避免或修复。另：批量上传功能现已恢复正常。————这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月3日 (二) 14:59 (CST)
据站外回复，系站点遭到外部攻击、运维方临时启用防护措施所致，目前暂无能力避免或修复。另：批量上传功能现已恢复正常。————这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月3日 (二) 14:59 (CST)
关于页面未过审版本提示的建议
页面未过审版本（例如Special:固定链接/7598274）的文字提示与正在等待审核或跳过审核的版本一样，均为“因为以下原因，您没有权限查看未审核的修订： 修订 #版本ID 正在审核中，返回最后的版本 ↺”，建议修改为“修订 #版本ID 未通过审核”等提示内容。--W3jc（讨论） 2024年8月16日 (五) 17:53 (CST)
- 确实离谱，已经被毙掉的版本怎么可能还在审核中……可以改成“修订 #版本ID
未能通过审核已被拒绝”之类的。--
她说我是被英国和法国同时盯上的土耳其猛男 2024年8月16日 (五) 21:34 (CST)
- 不过我很怀疑Moderation扩展能否支持这个部分的定制……--她说我是被英国和法国同时盯上的土耳其猛男 2024年8月16日 (五) 21:44 (CST)
- 不过我很怀疑Moderation扩展能否支持这个部分的定制……--
- 同意，應更新介面說明以避免混淆。—— Eric Liu 創造は生命（留言・留名） 2024年8月23日 (五) 13:07 (CST)
- 现在被拒绝的版本自己看的话会显示“已被拒绝”，但看别人被拒绝的版本依然是“正在审核中”。别问我为啥知道，今天在前人挖的坑摔死了--复活的奥斯曼 理论 及 其周边 -Ecole de Konstantiniyye- 2024年9月1日 (日) 17:40 (CST)
请求改良代码
最近在编辑的时候，发现常用的模板:Kairosoft Game出现了特殊情况，其指定文字参数在手机视图经常出现溢出状态，本来以为手机视图出框没啥问题，直到文本内容在电脑端变成了省略号，现在希望让文字参数能够自适应边框大小（包括手机视图）相关出错代码如下：
| 溢出文本展示 |
|---|
发行时间：2024年8月28日
游戏语言：包含中文
其他名称在代码里可以看到，原文ドラえもんのどら焼き屋さん物語的物語被吞了 |
求解--
max-width和text-overflow: ellipsis;white-space: nowrap;overflow: hidden;一套组合拳下来导致的，最大宽度调高然后把那串style删掉就行？涉及到宽度的地方还有点多……——bob1301（讨论） 2024年8月29日 (四) 16:32 (CST)
补充：该串中的溢出举例为源代码削减制作，因此不一定能还原实际状态，具体参见开罗游戏/作品--
- @playymcmc007 已尝试修改，看看是不是想要的效果。——GuoPC论 2024年8月30日 (五) 15:00 (CST)
- 我想要的效果是希望通过缩小字体来达到不出框的效果，换行会打乱排版影响美观--
讨论 ） 2024年8月30日 (五) 19:44 (CST)
- 我想要的效果是希望通过缩小字体来达到不出框的效果，换行会打乱排版影响美观--
无人回复。
全站样式表疑似被错误修改
U:AnnAngela-dbot于约半个小时前修改了MediaWiki:Gadget-site-styles.css。
根据原commit，修改者仅仅更改了两处颜色，但U:AnnAngela-dbot疑似额外地为.infoBox添加了border-radius，导致现在全站的{{info}}都有了圆角。
希望有人能复核。—— Chi_ZJ2讨论 2024年8月21日 (三) 18:52 (CST)
- 更正：bot没有问题，圆角也是修改者加的。但给全站的{{info}}加圆角确实是有意为之吗？……—— Chi_ZJ2讨论 2024年8月21日 (三) 18:59 (CST)
- 修改者的目的是让{{info}}适应深色模式，圆角是不是误加的？—— Chi_ZJ2讨论 2024年8月21日 (三) 19:01 (CST)
- @萌娘百科·娜娜奇，AnnAngela 理解很多人喜欢圆角，但现在是怎么个事呢？—— Jacklin612（☎·🧾） 2024年8月21日 (三) 19:58 (CST)
- 这种无端改圆角过于“一拍脑袋”了，真的看不懂。大洗的焦糖拿铁（讨论） 2024年8月21日 (三) 21:04 (CST)
- 难怪这两天看到的以{{info}}为基础的模板都变圆角了，我还以为是自己浏览器出了问题。话说回来，圆角化之后单个的模板看着确实好看了，但是一堆{{info}}列一起就有点难看……还是希望改回去——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年8月22日 (四) 23:04 (CST)
隔着Windows11呢这个圆角对于我们旧版ventor皮肤看得太难受了，快点把这个feature给rollback（--by LJL（讨论） 2024年8月23日 (五) 01:42 (CST)- 雖然無傷大雅，不過此種更改是否需要社群共識（或至少諮詢社群些許意見）？這看起來也不是萌皮介面運作所必須，有討論空間吧。—— Eric Liu 創造は生命（留言・留名） 2024年8月23日 (五) 13:04 (CST)
- 应该是为了适配MoeSkin的圆角样式，但是为什么要连Vector一起改了？图片的圆角样式就是单独给MoeSkin写的。而且info有圆角，其他常用的表格没有圆角，比如右上的infobox，最下方的navbox，都是直角的，只给info放圆角实在算不上是美观。——Xzonn（聊天） 2024年8月23日 (五) 13:17 (CST)
- 小心下一步就给你一起改了。如果让我揣测其想法的话，鉴于之前有说过不会在vector上面费心，有可能是只考虑moeskin的优化，而不考虑vector的显示效果了。--某FFF团的高级火法
（批判一番） 2024年8月23日 (五) 13:54 (CST)
- 小心下一步就给你一起改了。如果让我揣测其想法的话，鉴于之前有说过不会在vector上面费心，有可能是只考虑moeskin的优化，而不考虑vector的显示效果了。--某FFF团的高级火法
此处原由Chi ZJ2[更多]于2024年8月26日悬挂的、类型为“无人回复”的 MAR 因“這種問題不能以不回應來逃避”已被Ericliu1912[更多]于2024年8月28日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的10 日后 (于2024年9月6日凌晨) 存档；U:Chi ZJ2没有留言。
此处原由穆斯塔法凯末尔[更多]于2024年8月30日悬挂的、类型为“无人回复”的 MAR 已被Chi ZJ2[更多]于2024年9月10日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的21 日后 (于2024年9月21日凌晨) 存档；U:穆斯塔法凯末尔的留言是“无人回复的MAR是最后一个回复的话，就不要移除，否则存档时间会提前，我之前吃过这个亏。@Ericliu1912”
问题已解决。
文本切换显示按钮在MoeSkin下无法常显于画面内，只有在Vector皮肤下可以
用到模板“文本切换显示”的地方，其顶端的切换按钮只有在Vector皮肤下才能常显于画面内（往下翻页时按钮保持在画面顶端），而在MoeSkin皮肤下就无法常显于画面内了。用搜狗高速浏览器与Edge浏览器都是如此。
截图1，文字上方的文本切换显示按钮：
截图2，在MoeSkin皮肤下，往下翻页，文本切换显示按钮没有显示在画面内：
截图3，在Vector皮肤下，往下翻页，文本切换显示按钮能保持显示在画面内：
——Gfhjsghsdfh（用户•讨论•贡献） 2024年8月26日 (一) 22:59 (CST)
- 感觉像是布局样式的问题，是不是可以请界管看看？--W3jc（讨论） 2024年8月27日 (二) 11:59 (CST)
- 呃……这个没人回复么？——Gfhjsghsdfh（用户•讨论•贡献） 2024年9月2日 (一) 10:56 (CST)
此处原由穆斯塔法凯末尔[更多]于2024年9月2日悬挂的、类型为“无人回复”的 MAR 因“有新回复”已被Bicycle Hikawa[更多]于2024年9月3日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的21 日后 (于2024年9月24日凌晨) 存档；U:穆斯塔法凯末尔没有留言。
- 尝试访问对应页面未见所描述bug。但是，切换按钮显示位置在Moeskin下被显示在了页面偏下的位置，对阅读仍有影响。——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月3日 (二) 15:23 (CST)
- 我发现的时候是存在这个bug的，即切换按钮没有固定显示在画面里。现在能固定显示于画面，应该是此后有人修改过。但是这样又有一个bug：切换按钮固定显示时，显示在画面的中下方。我想原因应该是：正常情况下有程序使页面向上滚动的过程中切换按钮跟着向上移动到画面顶端后就停止继续向上移动，画面顶端就是切换按钮的移动上限，以此使切换按钮能固定显示；但现在，切换按钮的移动上限被错误地设到了画面中下部。这样就又造成了一个问题：将页面往下滚动使切换按钮固定显示后，切换按钮的移动上限以上的文本失去被选中的功能。（不过最后这个应该是使切换按钮固定显示的程序本身就有的性质，这个应该不是问题，无需改变，只需改变移动上限的位置。切换按钮正确地固定显示于画面顶端时其上方的文本其实也是无法选中的，只是没人会在意）——Gfhjsghsdfh（用户•讨论•贡献） 2024年9月3日 (二) 16:13 (CST)
- 非常神秘，我这里的按钮固定显示在所有条目内容的底部，并且从按钮出现的段落到底部都无法用鼠标选中，如果打开浏览器的控制台会自动进入MoeSkin.es5.js断点调试。--W3jc（讨论） 2024年9月6日 (五) 17:02 (CST)
- 不知道是不是有人改回来了，总之我现在切MoeSkin也看不到按钮了……——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月7日 (六) 01:49 (CST)
- @Bicycle_Hikawa 拉到页面外链底部看下，反正我的是显示在最下面。--W3jc（讨论） 2024年9月7日 (六) 22:19 (CST)
- 确实，我的也在最下面——这是一条由Bicycle_Hikawa写下的留言。去看看他最近在忙活什么？（有事戳这里） 2024年9月7日 (六) 22:28 (CST)
- @Bicycle_Hikawa 拉到页面外链底部看下，反正我的是显示在最下面。--W3jc（讨论） 2024年9月7日 (六) 22:19 (CST)
【BUG】同一版本会产生多个历史记录
状态： 已确认
- 问题
如御姐与正太、长谷川瑜ら、作家艾尔所示，有时候同一版本会在条目历史中产生多个记录。且这带来一个问题，AI审核仅将最上方的一个记录标记为过审，这导致在人工审核将所有记录标记为过审前，该条目无法查看，即使存在已过审版本（显示为没有权限查看未审核的修订）
- 复现步骤
- 对一已有条目进行编辑
- 尚不清楚触发条件
- 期望行为
同一版本在条目历史内仅产生一个历史记录
- 影响范围
全站
--某FFF团的高级火法 （批判一番） 2024年7月6日 (六) 00:07 (CST)
- (…)吐槽 我记得之前也有一个类似的Bug某个已被接受版本下面有好几条被拒绝的记录，不会师出同门吧？
此处原由机娘穆斯塔法[更多]于2024年7月20日悬挂的、类型为“无人回复”的 MAR 因“需要保留的讨论串”已被Dreammu[更多]于2024年7月21日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的10 日后 (于2024年7月31日凌晨) 存档；U:机娘穆斯塔法的留言是“挂一个MAR续个命，运维一时没法回复……”
此处原由Dreammu[更多]于2024年7月21日悬挂的、类型为“请求被搁置”的 MAR 因“已得到回复”已被冰风飘羽[更多]于2024年9月19日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的60 日后 (于2024年9月20日凌晨) 存档；U:Dreammu的留言是“等待运维回复”
问题已答复。
【BUG】黑幕中链接无法正常隐藏
状态： 已修复
- 问题
如题，从MoeSkin暗黑模式内测起，在黑幕中加入链接时，如果该链接为存在的内部链接，则该链接无法被黑幕正常隐藏（参见Special:Permalink/7631035）；若为外链，则外链标志无法被正常隐藏（参见Special:Permalink/7631038）。其它情况下不会出现异常。
- 复现步骤
在黑幕中插入外链或存在的内部链接
- 期望行为
黑幕中所有内容正常隐藏在黑幕中
- 影响范围
全站
--复活的奥斯曼 理论 及 其周边 -Ecole de Konstantiniyye- 2024年9月6日 (五) 09:54 (CST)
- (～)补充 在vector皮肤下，外链标志无法正常隐藏（而且是白的），其它正常。--复活的奥斯曼 理论 及 其周边 -Ecole de Konstantiniyye- 2024年9月6日 (五) 09:58 (CST)
- 这个问题我之前提过没人理被存档了，影响是否能被隐藏的似乎是链接有没有被访问过，对应页面访问过的链接隐藏不了，没访问的能正常隐藏。而且印象中好像不止内链有这个问题，具体哪里忘了orz。应该就是之前萌皮更新主题的时候开始出现的问题。—— 一颗小石子·
·Ishiko（讨论 · 贡献） 2024年9月6日 (五) 14:45 (CST)
- 然而现在更幽默，已经跟有没有访问过没关系了。--复活的奥斯曼 理论 及 其周边 -Ecole de Konstantiniyye- 2024年9月6日 (五) 14:47 (CST)
- 实测还是有关系的，找一个你没打开看过的标题，加内链装黑幕里面，一开始是能隐藏的，打开一次之后就隐藏不了了。—— 一颗小石子··Ishiko（讨论 · 贡献） 2024年9月6日 (五) 15:03 (CST)
- 实测还是有关系的，找一个你没打开看过的标题，加内链装黑幕里面，一开始是能隐藏的，打开一次之后就隐藏不了了。—— 一颗小石子·
- 然而现在更幽默，已经跟有没有访问过没关系了。--
·Ishiko此处原由穆斯塔法凯末尔[更多]于2024年9月10日悬挂的、类型为“无人回复”的 MAR 因“运营已回复”已被冰风飘羽[更多]于2024年9月19日移除。请您在本模板下方继续讨论！
讨论串原定于在 MAR 悬挂的14 日后 (于2024年9月25日凌晨) 存档；U:穆斯塔法凯末尔没有留言。
- 黑幕问题预计这两天内会解决--萌娘百科·啵奇塔（讨论） 2024年9月19日 (四) 14:43 (CST)
- 转述后续回复：已访问链接在黑幕未隐藏的bug应该已经修好了，但是那个外链标志的问题目前没办法修好，好像是一直以来就存在的问题。--冰风飘羽（讨论） 2024年9月20日 (五) 10:00 (CST)
问题已解决。
关于能否利用Widget实现目录分栏
一般实现目录分栏的做法是创建一个样式表，有点麻烦，也不直观。这也导致编辑者倾向使用{{隐藏目录}}来应对长目录问题。我在想能否写一个Widget来实现目录分栏的功能。
考虑到Widget的敏感性和创建门槛，我将以下代码交由相关技术人员审查。若无误，请求将其创建在Widget:TocMultiColumn（或者别的什么名字也可以）。
考虑到Widget的敏感性和创建门槛，若允许通过Widget实现，我申请相关技术人员审查以下代码，并将其创建在Widget:TocMultiColumn（或者别的什么名字也可以）。—— Chi_ZJ2讨论 2024年9月24日 (二) 18:34 (CST)
<includeonly><style>
.skin-vector .toc ul {
column-count: <!--{$count|default:'1'}-->;
column-width: <!--{$width|default:'initial'}-->;
column-gap: <!--{$gap|default:'initial'}-->;
}
.skin-vector .toc ul > li > ul {
column-count: 1;
}
.skin-vector .toctoggle {
float: right;
}
</style></includeonly><noinclude>仅供{{tl|目录分栏}}使用</noinclude>
—— Chi_ZJ2讨论 2024年9月24日 (二) 14:44 (CST)
- 有必要为了显示目录而创建分栏样式吗？对于折叠目录的条目完全可以通过浮动目录来跳转到各个段落。--W3jc（讨论） 2024年9月24日 (二) 17:16 (CST)
- 浮动目录也是折叠的，也是一列的。—— Chi_ZJ2讨论 2024年9月24日 (二) 18:21 (CST)
- 浮动目录不会受{{TocHide}}而折叠，本身也是单独滚动的。何种情况需要页顶目录进行分栏呈现？--W3jc（讨论） 2024年9月24日 (二) 18:56 (CST)
- 浮动目录不会受{{TocHide}}而折叠，因为它本来就是折叠的呀，得把鼠标移到按钮上才会滑出来。而且我怀疑浮动目录存在感不如页顶目录，读者的注意力不容易跑到那儿去。
- 目前使用分栏目录的条目，一般是出于目录过长的情况或（和）想要装饰的情况：璃月地区 蒙德地区 须弥地区 稻妻地区 枫丹地区 崩坏：星穹铁道 原神 Slow Loop 五彩斑斓的世界 飞翔之羊与盛夏之花 请问您今天要来点兔子吗？ pieces系列 总理俱乐部，用户页就不列出了。—— Chi_ZJ2讨论 2024年9月24日 (二) 19:12 (CST)
- 个人认为上述单纯目录分栏的效果并不是很好，分栏的目的就是为了减少目录的高度？如果是这样，是否可以将目录按照层级进行分列，在达到预设高度的时候新增一列？--W3jc（讨论） 2024年9月25日 (三) 10:31 (CST)
- 我觉得现在目录分栏的效果相当好（尤其是点兔），既实用又美观。您的设想理论上可以实现，但可能需要写js，我认为无此必要。而且编辑者手动调节列数，和设置最大高度自动调节列数，不是殊途同归的吗？那不如让编辑者手动调节更自由、直观些。—— Chi_ZJ2讨论 2024年9月26日 (四) 13:12 (CST)
- 手动调节也可以，只是目前分列和目录本身的层级没有关系。例如点兔的目录分为3列，但第2列第一项却是三级标题，使得原本层级的缩进显得混乱。这样排列给人的感觉还不如显示为一排的浮动目录。--W3jc（讨论） 2024年9月26日 (四) 16:43 (CST)
- 我理解您的意思了。这确实是一个缺陷。虽然这个缺陷可以通过给
li加break-inside: avoid-column;解决，但这会另外导致目录每列高度不同，导致底端无法对齐。如果要强制让每列垂直均匀分布使底端对齐，可能还是需要js的介入，其效果也未必尽人意，某列的行距可能会过大。 - 但我觉得这个缺陷也没有糟糕到致命的地步。①目录的每一项前都有序号。②目录每一列一般都有二级标题，这可以让读者快速感知每一列的“左基线”在哪里。③目录每一列往往还不止有二级标题，读者还可以根据不同级标题快速感知其缩进“左边缘”的在哪里。
- 3.2 完全版漫画
4 动画版
4.1 宣传绘
4.2 STAFF
4.3 各话列表
5 相关音乐
5.1 音乐列表
5.2 动画曲目
5.3 音乐活动
6 愚人节企划
6.1 历年愚人节主题
- 还以点兔为例，“完全版漫画”左边有一个“3.2”，下面有3个不缩进的二级标题、7个缩进和它相同的三级标题。这三个信号都可以帮助读者快速定位那个溢出到下一列的标题，而不至于感到缩进混乱。
- 归根结底这是一个排版问题，而且不存在完美的解答，不同方案都有其优缺点（我认为的浮动目录的缺点在前面已给出）。三权相害从其轻，各个方案孰好可能就见仁见智了。
- 最后夹一个私货：点兔的目录分栏是U:Sirogohan加的，我个人比较相信他的审美。—— Chi_ZJ2讨论 2024年9月26日 (四) 19:27 (CST)
- 我理解您的意思了。这确实是一个缺陷。虽然这个缺陷可以通过给
- 手动调节也可以，只是目前分列和目录本身的层级没有关系。例如点兔的目录分为3列，但第2列第一项却是三级标题，使得原本层级的缩进显得混乱。这样排列给人的感觉还不如显示为一排的浮动目录。--W3jc（讨论） 2024年9月26日 (四) 16:43 (CST)
- 我觉得现在目录分栏的效果相当好（尤其是点兔），既实用又美观。您的设想理论上可以实现，但可能需要写js，我认为无此必要。而且编辑者手动调节列数，和设置最大高度自动调节列数，不是殊途同归的吗？那不如让编辑者手动调节更自由、直观些。—— Chi_ZJ2讨论 2024年9月26日 (四) 13:12 (CST)
- 个人认为上述单纯目录分栏的效果并不是很好，分栏的目的就是为了减少目录的高度？如果是这样，是否可以将目录按照层级进行分列，在达到预设高度的时候新增一列？--W3jc（讨论） 2024年9月25日 (三) 10:31 (CST)
- 浮动目录不会受{{TocHide}}而折叠，本身也是单独滚动的。何种情况需要页顶目录进行分栏呈现？--W3jc（讨论） 2024年9月24日 (二) 18:56 (CST)
- 浮动目录也是折叠的，也是一列的。—— Chi_ZJ2讨论 2024年9月24日 (二) 18:21 (CST)
- 不要不加检查地往Widget里传参，有安全风险。——移动版用户 Bhsd 2024年9月25日 (三) 00:04 (CST)
- 不是哥们，你直接传参不搞转义吗？—— 屠麟傲血（讨论） 2024年9月25日 (三) 00:13 (CST)
- 抱歉，理解错文档了，我以为不设置escape就默认为htmlall。
- 这个是修改版，并且已经测试过，请审核：
column-count: <!--{$count|default:'1'|escape|validate:int}-->; <!--{if isset($width) && $width }-->column-width: <!--{$width|escape|validate:float}-->em;<!--{/if}--> <!--{if isset($gap) && $gap }-->column-gap: <!--{$gap|escape|validate:float}-->em;<!--{/if}-->- —— Chi_ZJ2讨论 2024年9月25日 (三) 00:45 (CST)
- 那么请问，这个widget预计会应用于多少页面？老实说它只能在vector使用，感觉应用范围不广啊。或许针对需要的条目写模板样式表就好了。—— 屠麟傲血（讨论） 2024年9月26日 (四) 19:20 (CST)
- 我本来想举Widget:Tochide和Widget:HideTocChildren的例子，前者只适用于vector，后者只设置了<style>、只嵌入到了56个条目。
- 想想还是算了，您说的有道理，vector已经没落了。
- 那么我撤回此申请。—— Chi_ZJ2讨论 2024年9月26日 (四) 20:32 (CST)
- 嘛，我说的是或许，如果页面数量不少的话当然也有必要。@Chi_ZJ2其实我本意是希望你评估使用数量的，但不知道为什么多说了一句话。—— 屠麟傲血（讨论） 2024年9月26日 (四) 22:27 (CST)
- @屠麟傲血 现在有27个条目应用了目录分栏，很少，这也是我觉得您说得有道理的原因之一。
- 我粗略翻了翻{{隐藏目录}}的所有嵌入，按目录高度约650～1100px、宽度约＜250px的标准，大约有58个条目把{{隐藏目录}}替换为{{目录分栏}}会更好，还有十几个条目我觉得可以两个模板一起用。有一些条目的目录长但没有用{{隐藏目录}}，我没法系统地找（今昨两天找我熟悉的条目时发现了约26个），但怎么着也还得有十几个。
- 最后合计已知的有约125—135刚出头。再加上我无法系统搜找的，保守估计可能有155＋。
- 不过为了提高这个Widget的含金量，我写了点javascript进去，实现了自动计算
column-width功能，以及@W3jc设想的按照层级进行分列的功能，不知道能不能抵偿使用数量较少的缺陷？（虽然跟Widget:HideTocChildren比其实已经挺多了，奈何人家能在moeskin上用……） 完整代码 <includeonly><script> window.RLQ = window.RLQ || []; window.RLQ.push(async () => { if (mw.config.get('skin') === 'moeskin') { return; } await mw.loader.using('mediawiki.toc'); const toc = $('.toc'), rootUL = toc.find('ul').eq(0); /* * 若用户未设置 column-width，则自动计算 */ <!--{if !isset($width) || !$width }--> rootUL.css('column-width', 'calc(1em + ' + $('.toc').find('.toclevel-1').width() + 'px)'); <!--{/if}--> /* * avoidBreakInside 功能： * 避免目录在内部丑陋地换列 */ <!--{if isset($avoidBreakInside) && $avoidBreakInside==true }--> function dfs(currentUL) { var flag = false; currentUL.children('li').each((_, ele) => { var childUL = $(ele).children('ul').eq(0); if (childUL.length != 0) { flag = true; dfs(childUL); } }); if (!flag) { currentUL.parent().css('break-inside', 'avoid-column'); return; } } dfs(rootUL); <!--{/if}--> var lists = toc.find('li'), listHeight = 1e9; lists.each((_, ele) => { listHeight = Math.min(listHeight, $(ele).outerHeight()); }); /* * 方式一：根据用户设置的高度自动计算列数 * 实现方法相当暴力，通常有 1～10em 的误差 */ <!--{if isset($height) && $height }--> var originHeight = rootUL.height(); rootUL.css('height', '<!--{$height|escape}-->'); var targetHeight = rootUL.height(); var count = Math.ceil(originHeight / targetHeight); rootUL.css('column-count', count); rootUL.css('height', ''); var columnHeight = rootUL.height(); for (var i = 0; i < (targetHeight-columnHeight) / listHeight * count; i++) { rootUL.append('<li class="TocMultiColumn-placeholder">PLACEHOLDER</li>'); } /* * 方式二：用户手动设置列数 */ <!--{else}--> rootUL.css('column-count', <!--{$count|default:'1'|escape|validate:int}-->); <!--{/if}--> /* * evenlySpread 功能： * 启用 avoidBreakInside 后，各列目录底端可能不对齐。此功能会让各列目录上下对齐 * 相当于 flex 布局下的 justify-content: space-between; */ <!--{if isset($evenlySpread) && $evenlySpread==true && isset($avoidBreakInside) && $avoidBreakInside==true }--> var columnHeight = rootUL.height(); var columnStart = 0, lastTop = 0; var marginTop = []; lists.each((index, ele) => { currentTop = $(ele).offset().top; if (currentTop < lastTop) { var count = index - columnStart; for (var i = columnStart+1; i < index; i++) { marginTop[i] = (columnHeight-listHeight*count) / (count-1); } columnStart = index; } lastTop = currentTop; }); for (var i = 0; i < lists.length; i++) { lists.eq(i).css('margin-top', marginTop[i] + 'px'); } <!--{/if}--> /* * 隐去占位符 */ toc.find('.TocMultiColumn-placeholder').css('visibility', 'hidden'); }); </script><style> .skin-vector .toc ul { <!--{if isset($count) && $count && !isset($avoidBreakInside) }-->column-count: <!--{$count|escape|validate:int}-->;<!--{/if}--> <!--{if isset($width) && $width }-->column-width: <!--{$width|escape}-->;<!--{/if}--> <!--{if isset($gap) && $gap }-->column-gap: <!--{$gap|escape}-->;<!--{/if}--> } .skin-vector .toc ul > li > ul { column-count: 1; } .skin-vector .toctoggle { float: right; } </style></includeonly><noinclude>仅供{{tl|目录分栏}}使用</noinclude>- —— Chi_ZJ2讨论 2024年9月27日 (五) 23:10 (CST)
- 嘛，我说的是或许，如果页面数量不少的话当然也有必要。@Chi_ZJ2其实我本意是希望你评估使用数量的，但不知道为什么多说了一句话。—— 屠麟傲血（讨论） 2024年9月26日 (四) 22:27 (CST)
- 那么请问，这个widget预计会应用于多少页面？老实说它只能在vector使用，感觉应用范围不广啊。或许针对需要的条目写模板样式表就好了。—— 屠麟傲血（讨论） 2024年9月26日 (四) 19:20 (CST)
屠麟傲血嘛，我只能说js不应该直接传参了，用元素的data属性传吧。另外waf限制，我编辑不了带js的widget，这个你得找管理。—— 屠麟傲血（讨论） 2024年9月27日 (五) 23:54 (CST)
所以这个现在实现了吗？人家还挺期待的说…… --
宇文西修ิิۣۣۖۖۖ特拉瑟☺ 2024年9月27日 (五) 23:32 (CST)
请求被撤回。
关于新增的评论区的小bug？
现在貌似评论区有点小bug？在页面被更改进入审核状态之后，评论区也会一并屏蔽。并且就页面修改过审之后（收到私信提示），评论区依旧会显示
“评论加载失败
pageInfo is null
pageId=神秘数字”
幻想乡的星辰（讨论） 2024年9月6日 (五) 18:52 (CST)